Digital video system using networked cameras

ABSTRACT

A digital video system including one or more video cameras and a video server connected to the one or more video cameras is disclosed. In an illustrative embodiment, the video server includes a computer having a central processing unit (CPU) for executing machine instructions and a memory for storing machine instructions that are to be executed by the CPU. The machine instructions when executed by the CPU implement a number of functions including identifying a failure mode of one or more cameras from one or more failure modes and executing a contingency function from one or more contingency functions based on the identification of the failure mode. The failure mode may be selected from a first, second and third failure mode. The contingency function may be selected from a first and second contingency function.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/453,595 filed Apr. 23, 2012, now U.S. Pat. No. ______, which is acontinuation of U.S. application Ser. No. 12/708,394 filed Feb. 18,2010, now U.S. Pat. No. 8,185,964, which is a continuation of U.S.application Ser. No. 11/125,795 filed May 10, 2005, now abandoned, whichis a continuation of U.S. application Ser. No. 09/808,543, filed Mar.14, 2001, now U.S. Pat. No. 6,891,566, which claims the benefit ofProvisional Patent Application 60/189,162 filed Mar. 14, 2000. Theentire disclosures of these applications are hereby incorporated byreference.

TECHNICAL FIELD

This invention relates to systems for accessing, recording, anddisplaying camera images from any of a number of remotely locatedcameras and, more particularly, to such systems that provide access toimages from one or more remote cameras over a public or private computernetwork.

BACKGROUND

With the continuing expansion and availability of public and privatecomputer networks it is becoming increasingly common to use thesenetworks for remote video and image surveillance. Historically, analogsystems have been used for CCTV systems for purposes such assurveillance. They include an analog video camera, a video cable, and amonitor/TV and/or a VCR recording device. Multiple cameras can be hookedto multiple recording VCRs for complete coverage of one or more targetareas. Specialized equipment known as a multiplexer or ‘MUX’ can be usedto allow multiple cameras to be hooked to a single recording/viewdevice. The multiplexer takes all video feeds in a sequential fashion,recording from one camera at a time. This allows the quantity of camerasto share a single recording tape. Besides the limitations of a serialtape system, additional limitations are introduced when the sequencingrate of the multiplexer is too slow to allow sufficient videorecord/view speed of a given camera view. Multiplexers are typicallyexpensive and have limited expandability without purchasing additionalcomplete systems. Also, the configuration of these systems usuallyrequires a skilled technician to be available at the systems site whichincreases the total cost of implementing such systems.

Digital systems have become more prevalent with the advent ofstandardized digital componentry. These systems utilize the same analogcameras and cabling, but introduce a capture card based collector. Thiscollector can be a proprietary digital device or a PC based computer,either of which has analog video inputs directly connected to it. Theseinputs convert the video to digital for viewing and recording and mayeven retransmit the signal to analog tape for recording purposes. Afactor limiting these digital systems is that an autonomous computer isrequired relatively near the video sources, sometimes with userintervention required at regular intervals. These machines are alsohardware bound. The number of capture cards is limited to the specificdesign of the collecting equipment. These systems are usuallyproprietary to a particular manufacturer and can be very expensive.Remote viewing is usually not available. Failover or redundancy functionis also limited and expensive, due to the fact that the system isusually duplicated for redundancy. As with the analog systems discussedabove, these systems also have configuration requirements that typicallyrequire a skilled technician.

There now exists commercially available networkable cameras that can beaccessed over networks running TCP/IP, including both LANs and globalnetworks such as the Internet. Ethernet-based digital video servers arenow common that are small, autonomous, and usually contain a web-basedconfiguration utility, as well as administration software. These camerascan be accessed and, in the case of pan/tilt/zoom (PTZ) cameras,controlled over the network using an assigned IP address and standardCGI-based URL syntax or other manufacturer-specified addressingprotocols. This allows an authorized user to control the product fromanywhere via the Internet or a dialup connection, and allows live imagesand image streams (video) to be accessed remotely using standard webbrowsers.

The video servers exist in two forms. One is a camera server that is acomplete product containing both a camera and a web server with anEthernet port. The other is a component based video server with inputsfor one or more analog video feeds, which the user can connect toconventional camera PAL or NTSC video feeds. The inputted analog videofeeds are converted to digital signals and sent from the video servers'Ethernet port. Thus, the video servers (whether integrated in as part ofa camera server or as a standalone unit) can be connected to theEthernet-based networks commonly used in businesses and other computerenabled sites. These video servers can be connected to these networksegments and are fully compatible with existing data on these networks.The video data can be received by standard PC computers which require nospecial hardware other than an Ethernet connection. The cameras can beeasily configured by a novice user who has very basic experience withthe Internet.

Ethernet video servers connect to an Ethernet connection and deliverdigital video based on user requests or internal scripting agents. Auser requests video images via standard CGI enhanced URL syntaxes. Thesesyntaxes control the image metrics and other features of the requestedvideo stream. The images are sent to the user as either static JPGsnapshots, or as continuous JPG streams. Rates to 30 FPS are easilyattainable. Since these images are delivered by Ethernet, the cameraservers are very robust. Although a requested image may not be receivedcompletely in an expected time frame, the video server will wait for theuser to complete its requests and processing. This virtually guaranteesdelivery of video, except where a connection to the video server isterminated.

When the user requests a video image or stream, the user is actuallyrequesting a static image that appears to exist as a file in a directorystructure on the video server. When the user requests a copy of thisimage, the video server actually updates it with a new image from thecamera source, and the user receives a picture that is up to date.Subsequent requests are to the identical file name, and the server doesthe updating of its content.

Although IP-based network cameras and camera servers have now evolved toa relatively advanced state, the use of a browser-based interface tothis hardware has seemingly impeded development of user interfaces thatprovide simplified, automated control over the acquisition of snapshotand streaming images over the network. Access to the camera imagestypically requires knowledge of the manufacturer's CGI-based syntax toaccess snapshot or streaming images. For example, to access a particularcamera, the user may have to specify to the browser an address in theform ofhttp//Uid:PW@111.111.111.111/cgi-bin/fullsize.jpg?camera=1&compression=.While this may be handled easily enough for a single camera bybookmarking or pulling the URL out of the browser's history buffer, thetask becomes more difficult when the user desires to change the accessparameters or where different cameras need to be accessed. Where theidentified camera cannot be accessed, such as for example due to animproper address being specified, the user may simply receive a standard“404 not found” error message that is not helpful in diagnosing eitherthe error or actual reason why access was not available.

Moreover, browser-based access is typically limited to either a snapshotmode or streaming images. In the snapshot mode, a single image isreturned when the appropriate URL is entered into the browser.Subsequent images from the camera are then accessed using the browser's“reload” or “refresh” button. In the streaming mode, once theappropriate URL is specified, the remote server or camera simply beginsstreaming image files back to the browser. This results in relativelyhigh network utilization that may be undesirable in a shared networkenvironment.

It is therefore a general object of this invention to provide animproved user interface and approach to the network transmission ofimages from commercially available network cameras.

SUMMARY

A digital video system including one or more video cameras and a videoserver connected to the one or more video cameras is disclosed. In anillustrative embodiment, a computer system is provided for addressingcamera failure modes and comprising a computer having non-transitorymemory for storing machine instructions that are to be executed by thecomputer. The machine instructions when executed by the computer mayimplement the following functions: identifying a failure mode of one ormore cameras from one or more failure modes; and executing a contingencyfunction from one or more contingency functions based on theidentification of the failure mode. The failure mode may be selectedfrom a first, second and third failure mode. The contingency functionmay be selected from a first and second contingency function.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred exemplary embodiments of the invention will hereinafter bedescribed in conjunction with the appended drawings, wherein likedesignations denote like elements, and wherein:

FIG. 1 is a block diagram showing a preferred embodiment of a digitalvideo system of the present invention;

FIGS. 2 and 3 together depict the process flow of the user interfaceclient application of FIG. 1;

FIG. 4 shows the contents of the initialization file used by the userinterface client application of FIG. 1;

FIG. 5 is a diagram depicting the main menu structure of the userinterface client application;

FIG. 6 is a flow chart showing the process used by the user interfaceclient to provide hardware setup information;

FIG. 7 is a diagram depicting the server setup form displayed by theuser interface client;

FIG. 8 is a diagram depicting the camera setup form displayed by theuser interface client;

FIG. 9 is a flow chart showing the process used to display a motion formthat allows the user to display and record video streams from one of thecameras;

FIG. 10 is a flow chart showing the process flow for the image viewerprogram of FIG. 1;

FIG. 11 is a diagram depicting the menu structure of the image viewerprogram;

FIG. 12a is a flow chart of the autoindexing setup process used by theimage viewer program;

FIG. 12b is a flow chart of the archive delete process used by the imageviewer program;

FIG. 13 is an overview of an OCX control used by the user interfaceclient and stream recorder client applications of FIG. 1;

FIG. 14a is a flow chart of a portion of the OCX control that is used toaccess individual snapshot images from the cameras used in the digitalvideo system of FIG. 1;

FIG. 14b is a flow chart of a portion of the OCX control that is used tointermittently access images from a streaming image server;

FIG. 14c is a flow chart of a portion of the OCX control that is used toaccess full video streams from a streaming image server;

FIG. 15 is a flow chart of a portion of the OCX control that is used inthe processing and recording of received images and image streams;

FIG. 16 is a flow chart showing the process flow for the stream recorderclient application of FIG. 1; and

FIGS. 17a and 17b together depict the motion detection routine used bythe user interface client application of FIG. 1.

DETAILED DESCRIPTION

Referring to FIG. 1, there is shown a network setup of a digital videosystem 20 of the present invention. The video system 20 includes aclient computer 22, a plurality of cameras 24, and one or morestandalone video servers 26. The client computer is connected to thecameras 24 and video servers 26 via a network 28 which can include aprivate network segment 30 and a public network such as the Internet 32.Other networked components can be used such as a networked storagedevice 34 and a networked file server 36. Some of the cameras 24comprise camera servers 38 which include both a video server and camerain a single integrated unit. The camera servers 38 can be, for example,Axis™ 200, 200+, or 2100 Ethernet cameras, available from AxisCommunications Inc., Chelmsford, Mass. (www.axis.com). The video servers26 can be Axis™ 2400, 2401, or 240 video servers, also available fromAxis Communications, Inc. The cameras 24 that are connected to the videoservers 26 can be industry standard PAL or NTSC video cameras. Clientcomputer 22 can be a conventional personal computer having an Intel™ orcompatible CPU running a Windows™ operating system and including anetwork interface card (not shown) for connecting to the 10/100 MbEthernet network 30 that uses the TCP/IP network protocol.

In accordance with the invention, client computer 22 includes a computerreadable memory, such as a fixed hard drive shown at 40 containingmagnetic media for digital storage of a user interface clientapplication 42 that includes a user interface program along with anumber of additional software components. The user interface program isin computer readable form (such as an .exe file). The additionalsoftware components include Microsoft™ Internet Explorer™ Internetextensions (included with Windows™ 95, 98, ME, 2000 and revisions), theWin32APl libraries (included with Windows™ operating systems), theWinInet.dll (also included with Windows™ operating systems), and acompression library such as IJL115.dll (available from Intel™) to decodeand recompress jpeg images received from the cameras 24.

Although the user interface client program 42 is shown as being storedon a hard drive 40, it will be appreciated that it can be stored onother digital storage devices as well. As used in the specification andclaims, “digital storage device” includes any of a variety of differentdigital storage devices, including magnetic media such as a hard disk orremovable disk, optical storage media such as a CDROM or DVD, ormagneto-optical media.

In general, the user interface client program 42 is operable to accesslocally stored camera data that uniquely identifies the cameras 24 andthen attempts access to those cameras over the network 28. The program24 is operable to verify access to at least those cameras 24 that arecurrently accessible, and to generate a user interface display 44 (onthe computer's monitor) that includes a display window 46 for each ofthe cameras 24 accessed over the network 28, and to display in each ofthe display windows 46 an image 48 received from the camera associatedwith that display window. As used in the specification and claims inreference to the program 42 or other executable program code, the phrase“operable to” [carry out some action] means that, when executed by amicroprocessor or other processing device of the computer, the programdirects the microprocessor to carry out or otherwise cause execution ofthe specified action.

In addition to the user interface client application 42, the hard drive40 also contains a stream recorder client application 50 and an imageviewer 52. Stream recorder client 50 permits high speed recording ofstreamed images (video) in a manner that minimizes network bandwidthutilization. Image viewer 52 permits browsing and viewing of archivedimages and video using a playback screen display 54. These two programs50, 52 are discussed farther below in connection with FIGS. 10-12 (forviewer program 52) and FIG. 16 (for stream recorder client 50). Allthree programs 42, 50, and 52 can be developed under Visual Basic 6.0and Visual C++ 6.0 and designed to run under Windows™ 95, 98, ME, NT,and 2000. User interface client 42 stores all camera, server and imagesettings to a Microsoft Access™ 7.0 database 56 and camera and userconfiguration data is stored in an .ini file 58. Digitized recordedvideo is stored directly on hard disk 40.

The user interface client application 42 is depicted in various levelsof detail by FIGS. 2-9 and 13-15, and 17 a-17 b, with FIGS. 2 and 3together representing the complete process flow through the applicationstarting from program launch. As shown in FIG. 2, once the user hasconsented to the licensing terms for use of the program, variousinitialization steps are performed, including:

-   -   1. getting camera and user configuration data from the .ini file        58;    -   2. initializing the database tables 56;    -   3. configuring the layout of the display form 44 on the client        computer 22;    -   4. reading the camera setups from the database table 56;    -   5. validating or creating the base path (directories) for        recording of images and image streams;    -   6. formatting user-selectable buttons for the client user        interface 44; and    -   7. retrieving embedded MAC addresses for purposes of validating        access to the cameras 24 identified in the database 56.

Thereafter, program 42 generates the user interface display 44 and theuser can start accessing images or video or can access various menuoptions shown in FIG. 5 for purposes of maintenance or changing of setupinformation. If the user has selected “start” to begin accessing imagesor video, then the next step is to initialize and test the camerasand/or servers by verifying the IP addresses, testing for a valid MACaddresses, and, if the IP addresses and MAC addresses are valid,assigning the user settings and enabling or disabling individual camerasor servers. As is known, the MAC addresses are unique to each camera andserver and can be queried via FTP requests to protected areas of thecamera or server's memory. Specific locations vary by manufacturer andrequire parsing and formatting to extract the required data, as will beknown by those skilled in the art. This enables the software to belicensed on a per-camera or per-server basis and can be used to preventaccess to any cameras or servers for which the user is not licensed.

For each camera in the database 56, all control information assigned tothat camera is stored in an array data type. This control informationincludes: Server Enabled, Server Name, Server Model, Server ID, ServerIP, Server Mac, Server User ID, Server PW, Server Port, Cam ID, CamModel, Cam Enabled, Cam Name, Cam Location, Cam Bldg, Cam Room, Cam Tel,Cam Room Contact, Cam Room Contact Tel, Cam Notes, Board Switch PortNums, Cam Thumb Image Name, Cam Fullimage Name, Record Image Name, CamThumb Compression Level, Cam Full Compression Level, Cam RecordCompression Level, Tool Tip Text, Last Pan, Last Tilt, Last Zoom, CamPTZ (y/n), Server Switch Action, Switch Caption, Switch Notes, EmailNotification, Email Address, Email Message, Enable Audio Alert, PlayAudio File, Last Update Time, Time Lapse Interval, Tie Breaker Count,User Disabled, System Disabled, System Disabled Message, RecompressionValue, Pan String, Tilt String, Zoom String, Home String. Theseparameters all control the camera and/or server used by the applicationand can be changed via a hardware setup form that is provided by thesoftware for the user and that is described further below.

Once all tests are complete, the process moves to FIG. 3 where theprogram ‘listens’ for digital input triggers generated by any of thecameras supporting this function. The client program 42 can listen forthese trigger events and either flash or highlight the window associatedwith that trigger input, show a high frame rate view (motion window) orbegin recording an image or series of images in the above formats.Trigger events are recorded to one of the database 56 tables byrecording the date, time and image name. The user can review and accessimages saved during triggering. As will be known to those skilled in theart, triggering is accomplished by enabling a CRON script in the serverthat will send a message to the client computer 22. Program 42 useswinsock controls to listen on a predefined port (1111 default). If atrigger message is received, the message is parsed for the server ID andport number. This information is compared to the relevant data fromdatabase 56 and the appropriate display window 46 is activated. The CRONscript comprises one or more control instructions generated by program42. Although the CRON script can be generated directly using a webbrowser on the client computer, it will be appreciated that generationof the CRON script by program 42 eliminates common typographical errorsencountered in manual CRON programming. Unique identifiers such as hostPC and port are automatically added to the CRON script by program 42.

Once the process begins listening for triggers it then finishesconfiguring the user interface display grid 44 on the client computer22. The display grid 44 shown in FIG. 1 is a 3×3 grid for up to ninecameras and it will be appreciated that any size grid can be specified,with the program 42 permitting the user to specify the number of windowsand the program then automatically scaling the images 48 to fit theresulting display window size. In configuring the view grid, the program42 may disable some camera images 48, showing instead a “No Video” orother message in the display box 46 associated with the camera 24. Thisdisabling may be due to, for example, the camera 24 being unreachable,disabled, or invalid. The software also sets the “record” indicators (ifenabled), the show port numbers (if enabled), and the camera caption(camera name, if enabled). These are discussed below in connection withFIG. 5.

Once the screen display 44 has been configured, the display loop beginsin which the program accesses and displays images from the cameras 24 onthe user's screen, with the software periodically updating the displayof each image 48. Starting with the first camera displayed, the programsequentially accesses each camera 24 and displays the received image 48in the box 46 associated with that camera, scaling the image to fit theuser's selected view size. The process runs through the display looponce for each camera 24, incrementing the current flame (display box)for each iteration until it has retrieved and displayed a snapshot imagefrom each camera. It then continues looping through the display loop,starting again at the first camera, and runs through the processcontinuously, sequentially polling each camera and updating each window46 with an updated image 48 received from the associated camera. As eachdisplay window is being updated, it can be highlighted using, forexample, a colored border to distinguish it from the remaining displaywindows. This allows the user to see the sequential polling process andis especially useful where the images change little if at all from oneupdate to the next.

The display loop of FIG. 3 continues until either a trigger event isreceived, a doubleclick by the user is detected on one of the displayedwindows 46, a stream request is made by double-clicking the port numberon the camera window, or the user cancels the monitoring, in which casethe program pauses. If the user selects a window 46 by double-clickinganywhere on its image 48, a motion form is displayed that permitsviewing a setting of various camera parameters, as well as permittingthe user to set recording parameters (such as number of frames tomanually record) and initiate recording from the camera associated withthe selected display window. The motion form and its use will bedescribed further below in connection with FIG. 9. The program checksduring the display loop to determine if the user has enabled recording.If so, the program checks user recording settings that can be setthrough the hardware setup process of FIG. 6 using the recording camerasetup tab of FIG. 8. These user configurable settings include selectionsto record all frames received, or interval recording where the user canspecify that frames are only recorded once every so many seconds orminutes. The user can also specify that recording should only occur whenmotion is detected in the received video. A preferred routine forimplementing the motion detection will be described further below inconnection with FIGS. 17a and 17b . Once these user settings are read,the program then checks scheduler settings that are also userconfigurable under the recording camera setup tab. These schedulersettings allow the user to specify certain hours during the day and daysduring the week when the recording is either to occur or be blocked.Scheduling can be done in 15 minute intervals. Every 15 minutes the usercan select No recording, Standard Recording (FIG. 15), or Video MotionDetection Recording FIGS. 17a-17b ). The program will compare thisschedule to the current time of day and adjust the recording functionsas necessary. This allows for up to 96 different recording schedules perday, far exceeding any typical user need. If recording is permitted forthe current time on this particular day, then the program proceeds tothe appropriate recording routine (record all frames, time intervalrecording, or motion detection) according to the user configurablesettings previously read.

As a part of the display loop, program 42 requests images or videostreams from one of the cameras 24. The requests are formatted asstandard CGI based URL syntax, i.e.:

http//Uid:PW@ 111.111.111.111/cgi-bin/fullsize.jpg?camera=1&compression=1).

The images are downloaded from the cameras 38 and servers 26 to theclient computer 22 where they are stored in a memory buffer, which canbe implemented in RAM. The buffer is parsed and augmented with formatteddate and time stamps, accurate to the millisecond. The image is assigneda name generated by the program based on the date and time of creation.The program 42 then saves the image to the hard drive 40 using thefollowing directory structure:

Mapped Drive and Root Path/Server Name/Camera Name/Year/Month/Day

This directory structure is generated in real-time as the recordingexecutes. The images are saved in one of the following styles, based onuser setup preferences:

-   -   Single Images: Images are saved under the Day directory in a        graphics file format such a jpegs. The file naming convention        used is hh mm ss.jpg, where hh is the current client computer        clock hour in 24 hour format, mm is minutes, and ss is seconds.    -   Multiple Images (video): Video images (i.e., time sequences of        individual images) are saved at the Month directory level as hh        00 00.jpx, where the .jpx extension represents a jpeg        concatenation file (streaming jpeg), which is a single file that        is built by the program 42 and that comprises a series of jpeg        images concatenated together, hh is the client computer clock        hour in 24 hour format. These .jpx files can be read and played        back by the image viewer 52.

Before storing the jpeg image files or concatenating the jpegs onto ajpx stream, the images can be compressed using the compression .dlllibrary noted above. In practice, it has been found that good qualityrecorded images consume an average of 7,500 bytes per image. Highercompression levels can yield a smaller file (down to 2,500 byes) at areduced quality. Higher quality images can also be recorded at a filesize of 70,000 bytes per image up to 250,000 bytes per image.

The program 42 can acquire images from the cameras in any of threemodes:

Snapshot: Request one image from the server and close the connection. Byrunning through the display loop rather than requesting a continuousstream from the server, the program iteratively requests snapshots fromthe cameras and servers thereby providing continuously-updated images ina manner that requires little bandwidth, with network utilizationtypically peaking at no more than six percent, regardless of networksize.

Stream Frame Mode: Connect in stream mode to each camera andsequentially cycle through each of the cameras, obtaining one or more ofthe streamed images from one selected camera, pausing the streaming fromthat camera, and then obtaining one or more streamed images from thenext camera until all of the cameras have been accessed and then paused.This cycle is repeated continuously until the user switches the programback out of this stream frame mode. In this mode, the processing isidentical to that of the snapshot mode, with the display loop extractingat least one frame from an open stream, and then indexing to the nextcamera. The connection is periodically reset to remain robustness. Thisapproach to image acquisition yields substantial performance gains overthe snapshot mode and is more efficient that a continuous stream. Thisconnection allows the video server to maintain an authorized connectionto the client computer, providing enhanced performance and ultimately,augmented received frame rates. Running in this mode requires morebandwidth than the snapshot mode, but will utilize less than the fullstreaming mode described below, since each stream is paused as theremaining connected cameras are sequentially accessed for a frame ofvideo. The video server buffers surplus video to the point of filling upits internal buffers, at which time the server stops grabbing videoframes until the buffer is depleted, or the server is reset. Thus, aswill be appreciated by those skilled in the art, this approach can alsobe used to control the frame rate of displayed and/or recorded video ina manner that minimizes the network bandwidth utilization. Thus, it canbe used for only select ones of the cameras and for recording at a framerate faster than that obtained by individual URL calls, but less thanthat provided by full streaming from the camera or video server.

Full Streaming Mode: Launch the stream recorder client 50 as a shelledprocess, pass the URL and various options via a command line syntax. Theclient computer connects in stream mode and retrieve images in aninfinite loop. The connection is reset periodically to ensure robustconnectivity across various network topologies. The received imagestream is then parsed for SOI (ASCII 255+ASCII 216) and EOI (ASCII255+ASCII 217) markers, which are the standard start-of-image andend-of-image markers. A buffer is built until these markers are found.When found, the image is displayed and that section is removed from thebuffer. This process is then reiterated until a timer expires thesession or the user manually closes the connection.

When recording, the stream recorder client 50 writes directly to thesame directory used by program 42, but uses a different namingconvention to avoid contention. This naming convention can beimplemented by appending a letter suffix to the filename of the jpxstream. For example, program 42 might record a filename as “11 0000.jpx”, whereas program 50 might record images obtained at the sametime as “11 00 00_s.jpx”. Since they are now uniquely named, there is noconcern of one program overwriting the image files of the other.

Referring now to FIG. 4, the .ini configuration file used for program 42will now be described. The WindowState=Normal (or Maximized) sets themain camera view grid as either normal, with the display being sizedbased on the Images_Across, Images_Down, Ref_Image_Width, andRef_Image_Height parameters. The Ref_Image_Width specifies the imagewidth of each display window 46 in units of twips (which is a knownmeasurement unit defined by Microsoft™). There are approximately 1440twips per inch. The image width is determined by the default imagemetrics that can be specified by the user via the defined inSetup/Software menu command. The Images_Across parameter specifies thenumber of cameras to be shown horizontally within the user interfacedisplay 44 and the Images_Down parameter specifies the number of camerasto be shown vertically. An exemplary 3×3 display grid (for a total ofnine camera windows) is shown in FIG. 1. In the event thatWindowState=Maximized, the entire screen is filled with theapplication's main window and displays the camera view grid in thecenter of the window based on the parameters noted above. TheDisplay=Image (or List) sets the initial display type, with “Image”resulting in a display of the view grid 44 with camera images 48 shownin the display windows 46 and “List” providing a textual list of thecameras and servers with no images.

The HighliteFrameColor specifies the hex RGB value for the currentupdate window, that is, it identifies the color used for the borderplaced around the camera window currently being updated at any one timeduring the display loop of FIG. 3. The default color is blue. TheFlashFrameColor provides the hex RGB value for the camera windowcorresponding to the camera for which a trigger has been received. Thedefault color is red. The ViewBackColor specifies the hex RGB value forinactive camera windows, with the default being grey. The TCPPortparameter specifies the IP port on which the camera server transmitsimages and the program 42 application listens. This information is usedin the base CRON script.

The RecordMode setting can either be SINGLE or MULTIPLE, whichrespectively correspond to the single image jpeg and video stream jpxfile formats discussed above. For “Single”, the received images arewritten to disk (or other non-volatile storage media) as a single jpegfile using the naming convention provided above. For “Multiple”, theimages are written as jpx streams, with the RecordMode parameter (“24”shown in FIG. 4) referring to how many jpx files are written per 24hours. This parameter can have any of the following values: 1, 2, 3, 4,6, 8, 12, 24. Thus, “1” means that the received stream of jpegs arewritten into a single jpx file over a 24-hour period, whereas “24” meansthat a new jpx file is started every hour, 24 per day. As mentionedabove, the jpx format is a straight concatenation of jpeg files and, bystoring the files with the .jpx rather than .jpg extension, the softwareavoids the possibility that a user opening the file will inadvertentlylaunch a standard .jpg viewer that might hang due to the large sizes ofthe jpx files.

The RecordThumbnails=TRUE setting is used to tell the software to recordthe displayed thumbnails rather than recording the image at the RecordImage parameter that is specified in the Camera Hardware Setup form ofFIG. 8. This setting causes the program to record the same image that isviewed in the display grid 44. When set to FALSE, the program accessesand displays one image (a thumbnail) from the camera and then accessesand records a second image (at a different size) without viewing. Thisallows for different image sizing and/or compression for viewing thanfor recording.

The RecordlmageBasePath sets the base directory path for recording allimages; that is, it sets the “mapped drive and root path” shown at theupper level of the directory structure shown above. The program willcreate all lower levels of the directory structure if they do notalready exist. An error message is displayed if the drive is notavailable or the directories cannot be created or accessed, and norecording will occur.

The Camera_Database setting is a pointer to the database 56 that is usedfor all camera and camera server settings. Other settings that may beless often accessed are:

-   -   DisplayWidth: Sets the default user interface display 44 size in        twips.    -   BorderWidth: Sets the width of the black spacing between all        thumbnail images in pixels.    -   SkipInactivePorts: TRUE—Thumbnails that are disabled will not be        displayed when program 42 is running.    -   ShowHighliteFrames: TRUE to show border around currently updated        thumbnail.    -   ShowRecordlndicators: TRUE to show the record LED status        indicator that can be included at a corner of the display window        for each camera.    -   ShowCameraCaptions: TRUE to show the title caption at the bottom        of the thumbnails.    -   ShowPortNumbers: TRUE to show the physical thumbnail port        numbers.    -   PingTimeout: The number of milliseconds to attempt a ping to the        video server before failure abort.    -   PingOnlmageRequest: TRUE to allow ping tests on each received        image burst.    -   CameraCaptionForeColor: Color of the camera caption in hex RGB    -   CameraCaptionBackColor: Back color of the camera caption in hex        RGB    -   HTTPPort: Http port number to access all cameras. This is a        global setting.    -   MaxFailOverCount: Number of failed camera requests before        shutting down the camera port. The display window 46 will show        “Unavailable”.    -   ReconnectAttemptlntervalSecs: Seconds to elapse before trying to        reconnect a failed camera.    -   DefaultEmailRecipient: Email address to use when sending a        motion alert.    -   EmailUserID: UserID used for email account access.    -   EmailUSerPW: User password for email account access.    -   ShowMotionBorder: TRUE to allow the video motion detection        routine to highlight the target window when motion is detected.    -   EnableStatusLog: TRUE to allow status info to be written to a        text log.    -   EnableErrorLog: TRUE to allow specific Error information to be        written to a text log.    -   StreamViewMode: When launching a streamer, the mode it starts in        can be:        -   0=Icon        -   1=Small frame window with text info only.        -   2=Normal window with video displayed.    -   StreamIntervalSeconds: Number of seconds to allow the streamer        to run before closing:        -   0=Run forever        -   1 to 84600=1 sec to 24 hrs run time before closing.    -   StreamMaxFPS: Maximum number of FPS to stream; 0=Max speed    -   StreamRecord: 0=no record on program launch, 1=record on launch.

Referring now to FIG. 5, there is shown the menu structure for the MainMenu displayed by the program 42 as a part of its user interface. In theDisplay menu, the “List” command displays the cameras as a text gridonly—no image is displayed. The “Thumbnail” command displays the camerasas a graphical grid, displaying images 48 received from the cameras 24using the display loop of FIG. 3. In the Setup menu, the “Hardware”command launches the Hardware Setup form which permits hardwareconfiguration using the process of FIG. 6. The user can add/delete/editthe different server and camera settings. Also in the setup menu is the‘Software’ command which launches a form that allows the user tographically modify the core setting of the .ini file. The ability tomanually edit the file also is available via the ‘Other’ Tab and thenthe first ‘Edit’ button. The ini file can also be edited with any usereditor such as Microsoft™ Notepad. The Archive menu contains a singlecommand, “Browse Archived Images” which launches the image viewer 52executable shown in FIG. 10. The Help menu includes a “Dump all ServerSettings” command which writes all server and camera data to a textfile. This information will be located in the application's directory ina file called CameraDump.txt. This information can be useful introubleshooting functional problems with the system.

FIG. 6 depicts the Hardware Setup routine that is invoked by selecting“Hardware” under the Setup menu. This process is used to add or deletecameras and servers, and to edit existing camera or server setups, ifdesired. The servers and cameras are shown in a tree structure on theleft side of a new window on the computer screen and, where an existingserver is selected, a set of server hardware setup tabs (shown in FIG.7) are displayed on the right side of the screen to permit configurationof various server parameters, including many of the control informationitems listed above. Where an existing camera is selected, the camerahardware setup tabs of FIG. 8 are displayed on the right side of thescreen for editing of camera parameters and control information notedabove. All panels for each of the tabs of FIGS. 7 and 8 includes anUpdate button to save changes made on the tab.

For the server hardware setup tabs of FIG. 7, the Connection tabprovides a display that permits the user to set the fundamental serversettings for the program's CGI base parameters. These options are usedin the URL requests to the server. The Connection tab contains the basicserver information. The fields are:

Server Name Name to identify the server. Server Model Name to identifythen camera. Server Enabled Check to enable, uncheck to disable. ServerSerial Number Authenticates the server. Numbers and Letters only. ServerIP Address IP address as 123.123.123.123 Server Root ID Root user ID.Can also be a regular User ID. Server Root Password Root user PW. Canalso be a regular User PW. Server Notes Notes for this Server, forreference only.

If the Server Root ID and Server Root Password are not used, the HostScripting tab will not function. The Connection panel also includes twobuttons:

Add New Server Creates a new Server. Delete Server Deletes an existingServer.

The Switch Inputs tab contains the information related to the digitalinputs on the server and can be used to set the program's preferencesettings for trigger responses from the server. This includes the ShowMotion form, Flash Window, and Record Image options shown in FIG. 3. Theports are disabled by default. The fields are:

Switch Port The port being edited. Switch Action The action to beperformed upon trigger. Switch Caption The name to identify the SwitchAction. Enable Audio Alert Enables or Disables an Audio alert segment.Play Audio Windows .wav file to play upon a trigger event.

The Relay Output tab provides a display that permits editing offunctional settings for latching or pulsing the server relay output. Asis known to those skilled in the art, this relay can be attached to asiren, autodialer, or other device compatible with the characteristicsand limitations of the server's relay. The fields are:

Enable Relay

Relay Caption

Relay Notes

The Host Scripting tab provides a display for programming or displayingbasic CRON scripts on the server. The basic script allows the server tobroadcast trigger events from the switch inputs. That is, the scriptenables to server to send messages to program 42 that are specific totriggering events on the server such as switch closures, infrared,microwave, magnetic, or other forms of sensors. For example, the baseCRON script used in Axis™ 2400 series servers is:

0-59 0-23 1-31 1-12 0-6/=xx:

alert -host yyy.yyy.yyy.yyy -port zzzz -message “Port Trigger”;

where xx is the server port 1-4, yyy.yyy.yyy.yyy is the IP address ofthe client computer 22, and zzzz is the port specified in the .ini filefor communication between the program 42 and the server. The fields onthis tab are:

Enable Script Enable/Disable CRON script activation. Script Text CRONscript text.

The Host Scripting panel also contains four buttons:

Template Sets a basic CRON script for triggering. Clear Clears theScript window. Download from Server Retrieves existing CRON script fromthe Server. Upload to Server Sends the Script text to the Server.

For the camera hardware setup tabs of FIG. 8, the Info tab allows theuser to set the camera name, Pan/Tilt/Zoom (PTZ), and text referencefields for each camera, as well as enable or disable the camera. Inparticular, the Info tab includes the following fields:

Camera Name Name of Camera. Camera Model Camera Model; Select from list.Camera Enabled Enables/Disables the Camera Image. Enable Camera MovementIndicates whether a camera can move. Camera Location This text is forreference only. Camera Bldg This text is for reference only. Camera RoomThis text is for reference only. Camera Room Tel This text is forreference only. Camera Room Contact This text is for reference only.Camera Room Contact Tel This text is for reference only. Camera NotesThis text is for reference only.

The Presets tab allows the user to define any quantity of user definedpresets for Pan/Tilt/Zoom. The user is shown a thumbnail of a staticsnapshot for any new positional requests. The fields are:

Preset Views Enables the user to Add/Change Views Preset Notes TextNotes for the selected preset. Pan Pan Value Tilt Tilt Value Zoom ZoomValue

There is one button:

H Sets the Preset to HOME

There are three slider controls:

Pan Pan Value Tilt Tilt Value Zoom Zoom Value

The Displayed Image tab allows the user to set the image size andcompression level request for the camera server image retrieval. Theseparameters are mapped against CGI type parameters defined by the server.The user representations are simplified terms versus the CGI syntax.Three image styles are defined here. Each style is set for the threeimage request types. This value is used by the server when sendingrequested images to the application. The fields are:

Thumbnail Image Main View with all cameras. Full View Image DetailedView of a single camera. Record Image Recorded Image style.

The Thumbnail Image is displayed on the Main form with all the othercamera views. The Full View Image is displayed on the Motion form. TheRecord Image is used whenever a save request is made by the application.Each Image style has a related compression value. The compression valuesare selectable for each Image style. The following considerations shouldbe used when selecting the Image styles:

Image Size

Largest images: slowest access, largest file size Smallest images:fastest access, smallest file size

Compression Value

Lowest compression: best image quality, slowest access Highestcompression: worst image quality, fastest access

The Switch Inputs tab allows the user to bind any or all availabledigital switch ports to a display window. That is, the digital switchinputs must be bound to camera ports. This setting tells the applicationwhich cameras to record/notify when a trigger event occurs and allowsthe application to notify the user on screen which port trigger(s)is/are associated with a camera view. Each defined switch input islisted with a check box that can be selected to bind the camera to thatswitch input.

As mentioned above in connection with FIG. 3, the Recording setup tabpermits the user to set automatic recording options for intervalrecording a camera. The interval is expressed in seconds. The camerawill record an image at the specified interval if the hardware can meetthese expectations. Otherwise, the image is recorded as quickly aspossible after the interval has expired. The fastest interval that canbe used is derived from observing the cycling rate of all cameras. On aquality system the fastest interval is about ¼ second for any camera.The fields are:

Interval Recording The camera will record images at a set interval.Record an Image every . . . The Interval to record images automatically.Compression Index This value sets the save compression value.

The compression value is used by the compression library to set theamount of compression for image saves. The lower the number, the higherthe compression. The range is between 5 and 40. The most commonly-usedvalue is between 30 and 35.

The Email tab permits the user to set an email address to which an emailnotification will be sent upon occurrence of a trigger event. An imagefrom the triggered camera can be attached to the email. The Performancetab permits the user to specify a unique User ID so that the camera orvideo server administrator can set or limit the bandwidth of videotransmission on a user-by-user basis.

When a user double-clicks on a camera window 46, the program 42 bringsup a Motion Form which runs the process shown in FIG. 9. This permitsthe user to bring up a detailed view of the image from a particularcamera, with the image being updated at an increased rate. Completecamera and server information is displayed on this form. The user canPan/Tilt/Zoom supported cameras, click on preset positions, recordimages, or display any trigger events.

FIG. 10 depicts the process flow provided by the image viewer program52, which can be, but need not be, a separate executable than program42. This process can be launched from within program 42 using the“Browse Archive Images” command in the Archive menu of FIG. 5. Thisprogram 52 can include authentication capability to provide the userwith access to only those archived images that have come from serversaccessible to that user. This is indicated in FIG. 10 where the programreads the database for defined servers and parses the record path formatching servers. Then it will display a tree structure showing onlythose archived images and streams that came from cameras or serversdefined in the database for that user. Once the user has selected anarchived jpg or jpx file, the image is brought up on the screen and, forjpx streams, the user can play, pause, stop, frame advance and reviewusing buttons that emulate a VCR panel. A refresh button can also beprovided to reload the archive if additional images are being written toit in the background by the user interface client program 42. The imageviewer program 52 can include an autodelete function, in which case afive minute timer is started. The program then checks the archive ageagainst user date settings, and deletes the archived .jpg and .jpx imagefiles that are older than the specified date or time period. The program52 can also include an autoindex feature which, when enabled,automatically indexes the archived jpx files every hour to build anindex into the jpx file for quick access by the program into any pointin the jpx file. This index feature is discussed next. If the autoindexfeature is not enabled, then the index is not built until the first timethe jpx file is loaded.

In installations where very high speed recording is being performed, thejpx file can become quite large. A typical jpx file for an hour of videois 1 to 5 MB, while high speed recording can easily exceed 20 MB andeven reach 100 MB. Since the jpx is purely concatenated JPG images,aligned head to tail, the only way to view the images within the jpxfile is to parse the SOI and EOI markers and display the image inbetween them. For incremental playback, this process is easilycontrolled. However, when a user wants to “rewind”, “fast forward”, orrandomly jump to a portion of video, this process requires the program52 to process from its current position and read all video frames inbetween. Jumping over frames does not work for these files since, inorder to most efficiently store the images, the images within the jpxfile are relatively unique in length. This process of reading in all ofthe frames can be undesirably slow when the jpx file is large. Toovercome this issue, the image viewer program 52 creates an index of theSOI and EOI markers of each image in the jpx file. This index is storedas an array of pointers into the jpx file and is stored using .ndx asits filename extension. The program 52 will look for this index and useit to load the image pointers instead of reading the entire jpx. Theimage pointers identify the memory locations of the SOI and EOI markers,thereby allowing the program to easily locate and retrieve individualimages contained within the jpx file. The ndx file can be loaded in lessthan a second, as compared with jpx load times of up to a minute ormore, depending on jpx size. The index is created on the first useraccess to the jpx image file or when an autoindex event is processed, asdescribed above. Successive requests from the user to a jpx will allowthe program to read the ndx file rather than a conventional approachwhich would entail reading the entire jpx file. With the index file, thepointers can be read into memory and accessed quickly, even for verylarge jpx files.

The ndx index file also makes possible the use of the image viewerprogram 52 as a plug-in for commercially available web browsers. Inconventional browser-based retrieval of video, the video files can bequite large, and the user can therefore typically only request a smallnumber of frames. The user does not know the stream size, frame count,index of time pointers, etc. By implementing the image viewer 52 as aplug-in component for a web browser, viewer can be used to provide webpage access from a web browser to stored jpx images. This alleviates thenecessity of a specialized software product to view the archives. Sincethis image viewer plug-in utilizes the ndx index file, the user canretrieve a wealth of video specific content in a very short period oftime, allowing realtime display of video (assuming the user hassufficient bandwidth) of the Internet or other network.

When implemented as a plug-in, the image viewer 52 can also be used toview “live” a stream that is being recorded on a network server. Thiscan be accomplished using server software that records the jpx files inthe manner described herein, with the image viewer then only parse thetarget jpx file on the network server for the latest video frame. Bydisplaying this video frame, the user sees live video that originatedfrom the camera server, but is being supplied by what can be a muchhigher performance network server. Thus, since the user is now viewingrecorded video from a higher performance server, the number ofsimultaneous connections to the video feed is highly scalable byimplementing standard web server components. This is advantageous sinceall Ethernet video servers are highly susceptible to overload frommultiple user requests and performance is degraded linearly with eachsimultaneous connection.

FIG. 11 depicts the main menu for the image viewer program 52. The“Tree” command under the Browse Mode menu item allows the user to browseall permitted archives by server, camera, date, and type. The “Date”command allows the user to search by date/time for a selected server andcamera. The ‘Directory List’ command lets the user browse all attacheddrives manually. The Indexing command under the Maintenance menu allowsthe user to set the autoindexing features described above. The processused by the image viewer program 52 for setting up the autoindex featureis shown in FIG. 12a . The “Delete” command under the Maintenance menuallows the user to manually delete archives or automatically deletearchives older than a selected date/time stamp. FIG. 12b depicts theprocess flow when the “Delete” command is selected. The “FormatConversion” command under the Tools menu allows the user to convertimages to other standardized formats. The Display Mode menu allows theuser to playback the images either as thumbnails (like images 48displayed in the windows 46 generated by the user interface clientprogram 46) or in a cinema (fullscreen) mode.

Rather than using the ActiveX control provided by the camera/servermanufacturer, the user interface client program 42 and stream recorderprogram 50 utilize their own ActiveX control to interface with thecameras and servers. An overview of this OCX control is shown in FIG.13. Further details of the control for obtaining and displaying an imageare shown in FIGS. 14a-14c , and further details of the control forobtaining and recording an image are shown in FIG. 15. Theimplementation of a suitable OCX control using the process steps shownin these figures will be known to those skilled in the art and thereforeno further elaboration of the design of this control is necessary.

Referring now to FIG. 16, there is shown the program flow of the streamrecording client program 50, which is a separate executable that permitshigh speed recording of image streams (video) in a manner that minimizesnetwork utilization. The program 50 enables the streaming output fromthe camera servers using the OCX control described above internallywithin the program as direct subroutine calls. Streaming is initiatedusing a CGI enabled URL that is sent in the same manner as describedabove for the user interface client program 42, except that the CGIsyntax is set to zero to indicate streaming output from the server. Asindicated in FIG. 16, the program 50 utilizes a timer to reset theconnection to the server before it is automatically terminated by thenetwork. More specifically, for some networks, such as the Internet, aconnection cannot typically be permanently held, but rather will beterminated automatically after a period of time (e.g., 50-70 minutes).The program 50 avoids this problem and enables nearly uninterruptedstreaming by automatically resetting the connection before the externaltermination and then continuing to append the streaming images onto theend of the jpx file. This can be done with the loss of little or nostreaming data from the camera.

Referring now to FIGS. 17a and 17b , the video motion detection routineof program 42 is used to allow the recording of images to be performedonly when a moving subject is present. When enough motion is present,the system will begin recording video until motion has stopped. Whenmotion is sensed according to this routine, the program will perform anyor all of the following functions:

-   -   record video up until video motion is no longer sensed and an        “extra frames” count is exhausted;    -   send an email to a user as selected in the hardware setup panel        based on settings from the .ini file;    -   attach an image to the email of the first frame of video that        motion was detected on;    -   show a yellow border around the target window where motion was        detected;    -   announce motion ON and motion OFF with two way files, hello.wav        and goodbye.wav, which the user may reset to any sounds        desirable.

FIGS. 17a and 17b detail the logic flow of this process. In general, themotion detection routine uses RGB color component filtering of theactual pixel data. By breaking down the image into these components, thevalues of each color component per pixel is represented as a decimalvalue of 0 (No color) to 255 (bright color). These values are comparedto user-defined settings in the program 42 for filtering, allowingspecific component or combined colors to exhibit reduced or enhancedmovement sensitivity. For example, outdoor cameras are very prone tofalse triggering when blowing grass/leaves or shadows are present. Byfiltering out more green component, false triggering is reduced to avery acceptable level. This gives the program the ability to use motiondetection in a much more broad range of use than other comparablesystems.

The process begins by taking the first image (i.e., frame) of a videosequence and placing it into a buffer where it will be used as areference image. The reference image is compared to subsequent videoframes on a pixel-by-pixel basis. Preferably, the reference image iscompared to subsequent images as they are being received (i.e., as soonas they are received) by the client computer so that the program isoperable to provide real time motion detection. For each pixel in thecurrent image, the program performs a comparison of the color componentvalues for that pixel with the color component values of thecorresponding pixel in the reference image. If the difference in colorcomponent values for corresponding pixels from the two images differ bymore than a preselected amount, the program generates a motion detectsignal which can be implemented as the Record Flag shown in FIG. 17b .For each of the RGB color components, a separate counter (Count_Red,Count_Green, and Count_Blue) is used that tracks the total number ofpixels within the current image for which that color component valuediffers from that of the reference image by more than a preselectedamount. This is done using a user-selectable filter levels for each ofthe color components. In particular, if for a particular RGB colorcomponent, ABS(P_(ref)−P_(cur))−FilterLevel>0 then the Count isincremented for that color component. Separate filter levels are usedfor each color component and these filter levels can be set by the user.As will be appreciated, the FilterLevel is an offset that aids inremoving unwanted noise inherent in video sources, as well as“pixelation” or “tiling” inherent in jpg image sources undercompression. When the entire image is processed, the Count_Red,Count_Green, and Count_Blue counters are compared to a user specifiedminimum, which can be different for each of the color components. If allthree exceed their respective minimums, motion is considered present andthe Record Flag is set to tell the program to proceed with recording.

Once motion is detected, the system records video and continues thepixel comparisons for each subsequent frame until the routine detectsthat motion is no longer present. To prevent the recording from endingbefore a subject has completely left the camera's field of view, theprogram continues recording until a specified number of extra frameshave been recorded. This is carried out using an Extra Frames counterthat is decremented once per frame starting with the first framereceived after no further motion has been detected. As with the othercounters, the number used for this counter can be user specified.Periodically, a new reference frame is selected from the video stream.This is done at regular intervals as specified by a user “RefreshInterval” setting, which is an image frame count. This Refresh Intervalis used in conjunction with a frame counter C_Ref such that, once theC_Ref counter exceeds the Refresh Interval number, the reference bufferis emptied and the counter reset to zero.

The core function of the video motion detection is based on a count ofpixels for which at least one color component value differs from that ofthe reference image by a preselected amount. Minimum object sizedetection can be implemented using the routine of FIGS. 17a and 17b withthe addition of an X by Y (width by height) template that scans the X byY pixel information. If all pixels have a color component value thatdiffers from that of the reference image by a preselected amount withinthe X by Y area, motion is detected. The program highlights the objectwith a bounding rectangle. This process can be used to filter outobjects that are too small to be considered motion.

Apart from minimum object size detection, the program 42 is alsooperable to permit the user to specify a region of the camera's field ofview so that the program performs the pixel comparisons only for thosepixels located within that region. This region of interest processing isimplemented by providing the user with the ability to mask out specificportions of a video frame, which will then be ignored by the motiondetection. This concentrates the motion detection to specific regions ofthe screen. Typical region of interest masks employ grids or regionsbased on a grid array of squares. These areas are selected to mask outthe regions. This tends to be somewhat granular in use. The program 42uses a pixel based approach to masking the images. The user firstcreates a region of interest by defining the mask using the computermouse to paint a black or other colored area on the image. The paintedareas represent those portions not desired for use in detecting motion.A tool palette of square or other shape may be employed to create thepainted mask. The mask is converted to a black and white mask and savedas a .bmp file based on the camera name. When video motion detection isused by the program, individual pixels from the reference and currentimages will be compared only if the corresponding mask pixel is notblack. Users may edit the mask in Microsoft™ Paint or other image editorto refine the mask to the pixel level.

Implementations of this type of streaming media have a commondifficulty; namely, Ethernet connectivity is at best a highly reliablebut not a totally reliable connection. Occasionally, power fluctuations,excessive image requests, overloaded or failing networks and a multitudeof other issues can cause the connection to the camera to fail.Competing implementations often cause the application to abnormallyabort or stop responding, requiring the user to close and restart theapplication. This condition is very serious since recorded video willnot be available while the program is not responding. The user interfaceclient program 42 and stream recorder client program 50 address thisissue by identifying three modes of failure, and providing contingencyfunctions to overcome these problems. These modes are:

-   -   1. failure upon connect;    -   2. failure upon image request (read); and    -   3. failure during midstream read of image.

Failure types 1 and 2 are easily overcome by the implementation of thedefault timeout of failed requests by the Wininet.dll and its relatedcomponents. The program can count these failures on a per camera basisand optionally shut down the camera and reattempt access periodically.This maximum failure count and reattempt connections are user selectableon a global scale.

Type 3 failures are usually serious and can cause the program to stopresponding. By executing the request asynchronously or in a workerthread, the request can be timed and if abnormally long, cancel therequest and try again. This allows the application to continue tofunction consistently. Preferably, the program utilizes both methods toinsure robust connectivity.

It will thus be apparent that there has been provided in accordance withthe present invention a digital video system and computer programtherefor which achieves the aims and advantages specified herein. Itwill of course be understood that the foregoing description is ofpreferred exemplary embodiments of the invention and that the inventionis not limited to the specific embodiments shown. Various changes andmodifications will become apparent to those skilled in the art. Forexample, although the invention has been described as it would beimplemented using TCP/IP network cameras and camera servers, it will beappreciated that the invention can be used in conjunction with otherimage sources. For example, rather than specifying a URL to access aparticular camera, the invention could be used to specify a memorylocation or utilize a .dll file to access images from, for example, avideo capture card, USB or IEEE-1394 (Firewire) ports. All suchvariations and modifications are intended to come within the scope ofthe appended claims.

What is claimed is:
 1. A computer system for addressing camera failuremodes and comprising a computer having non-transitory memory for storingmachine instructions that are to be executed by the computer, themachine instructions when executed by the computer implement thefollowing functions: identifying a failure mode of one or more camerasfrom one or more failure modes; and executing a contingency functionfrom one or more contingency functions based on the identification ofthe failure mode.
 2. The computer system of claim 1, wherein the failuremode is selected from the group consisting of a first, second and thirdfailure mode and the contingency function is selected from the groupconsisting of a first and second contingency function.
 3. The computersystem of claim 2, wherein the first failure mode is a failure uponconnect of the one or more cameras to a network and the firstcontingency function is shut down of the one or more cameras andreattempt access by the server to the one or more cameras periodically.4. The computer system of claim 3, wherein the executing functioncomprises executing the first contingency function based on theidentification of the first failure mode.
 5. The computer system ofclaim 2, wherein the second failure mode is a failure upon an imagerequest from the one or more cameras and the first contingency functionis shut down of the one or more cameras and reattempt access by theserver to the one or more cameras periodically.
 6. The computer systemof claim 5, wherein the executing function comprises executing the firstcontingency function based on the identification of the second failuremode.
 7. The computer system of claim 2, wherein the third failure modeis a failure during midstream read of an image from the one or morecameras and the second contingency function is a timed asynchronousrequest.
 8. The computer system of claim 7, wherein the executingfunction comprises executing the second contingency function based onthe identification of the third failure mode.
 9. A method for addressingcamera failure modes comprising: identifying a failure mode of one ormore cameras from one or more failure modes; and executing a contingencyfunction from one or more contingency functions based on theidentification of the failure mode.
 10. The method of claim 9, whereinthe failure mode is selected from the group consisting of a first,second and third failure mode and the contingency function is selectedfrom the group consisting of a first and second contingency function.11. The method of claim 10, wherein the first failure mode is a failureupon connect of the one or more cameras to a network and the firstcontingency function is shut down of the one or more cameras andreattempt access by the server to the one or more cameras periodically.12. The method of claim 11, wherein the executing step comprisesexecuting the first contingency function based on the identification ofthe first failure mode.
 13. The method of claim 10, wherein the secondfailure mode is a failure upon an image request from the one or morecameras and the first contingency function is shut down of the one ormore cameras and reattempt access by the server to the one or morecameras periodically.
 14. The method of claim 13, wherein the executingstep comprises executing the first contingency function based on theidentification of the second failure mode.
 15. The method of claim 9,wherein the third failure mode is a failure during midstream read of animage from the one or more cameras and the second contingency functionis a timed asynchronous request.
 16. The computer system of claim 15,wherein the executing step comprises executing the second contingencyfunction based on the identification of the third failure mode.
 17. Acomputer system for addressing camera failure modes and comprising acomputer having non-transitory memory for storing machine instructionsthat are to be executed by the computer, the machine instructions whenexecuted by the computer implement the following functions: identifyinga failure mode of one or more cameras from a first, second and thirdfailure mode; and executing a contingency function from one or morecontingency functions based on the identification of the failure mode.18. The computer system of claim 17, wherein the first failure mode is afailure upon connect of the one or more cameras to a network.
 19. Thecomputer system of claim 17, wherein the second failure mode is afailure upon an image request from the one or more cameras.
 20. Thecomputer system of claim 17, wherein the third failure mode is a failureduring midstream read of an image from the one or more cameras.